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REMARKS 

The Examiner objected to the claims 1 -20 as being anticipated by Benowitz et al. (US 
Publication No. 2003/0236847). The Examiner argued that Benowitc teaches that if no 
authorisiation code is detected 156, the CAS will determine 160 whether Ac sender is on an 
exclusion list by comparing the email address, IP address and/or MAC address of the sender with 
the $ame identifying information on the exclusion list. Applicant respectfully traverses this 
objection and has amended the claims to clarify the differences of Benowitz ct al. 

Benowitz et al. is directed toward?; a communication authorization system (**CAS") that 
determines whether incoming communications should be allowed to reach the intended recipient 
by checking the communication for a proper communication authorization code. The 
communicatiou authorization code is a code set by the CAS and communicated to the sender for 
inclusion in any communications sent by the sender. The CAS includes an authorization code 
system that maintains, admini^ers and transmits the authorisation codes to future senders (paras. 
71-73). 

The Examiinerhas directed the applicant to paragraphs 8> 10, 87, 91, 93 and 102 of Bewnowitz et 
al. These paragraphs describe the use of an exclusion list containing either an acceptable email 
address (paragraphs 8 and 10), or a list of acceptable authorization codes (paragraphs 87» 91 , 93 
and 102). As explained in Benowitz et al., these exclusion lists are generated by the user housing 
a list of acceptable email addresses (paragraph 8), the recipient manually screening incoming 
mail (paragraph 1 0), user or system defined niles (paragraph 87) and, the sender adds a valid 
authorization code to the email message (paragraph 91). Operation of the exclusion hsts are 
described as being maintained by the CAS or outijide and independent of the CAS (paragraph 93) 
and, a mail server stripping an authorization code from an incoming mail message before passing 
the code and the address to a database server (paragraph 102). 

Benowitz et aL teaches the addition of an authorization code by the sender to an email message 
to be sent and authorized. The sender first obtains the authorization code by: i) contacting the 
intended recipient via non-system communication to obtain a proper authorization code; or, ii) 
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contacting a notification/aathorization service via the user interface to obtain a proper 
authorization code, (paragraph 63) 

The CAS docs not store sender information in at least one recipient permitted sender database, 
and store sender information associated with all members of a recipient group in at least one 
recipient group permitted sender database. The CAS docs not detormhie whether the sender has 
been autboriy.ed by the recipient and if the sender has not been aalhorizcd by the recipient, 
comparing sender infomiation in the email message received from the sender with corresponding 
sender information stored in the recipient group PSD to determine if the recipient group has 
authorized the sender. The CAS does not decide to forward an email message on the basis that 
another user, a member of a recipient group, lias authorized the sender. The CAS does not add 
sender infonnation stored in the recipient group PSDto the recipient PSD. 

The present invention docs not rely upon pre-detennined audiorization codes to mthenticate 
incoming communications. Farther, the present invention docs not screen all communications to 
only permit communications containing a pre-detettnined authorization code that was added to 
the email message by the sender. The present invention provides for a system for tbrwarding 
email messages wherein an incoming message is forwarded through to the intended recipient if 
the sender information in the message matches sender information in cither the recipient's 
permitted sender database, or sender information in at least one recipient group pentiitled sender 
database of which th© recipient is a member. Thus, the present invention allows for tlie receipt of 
an email where either the recipient has approved the sender, or a member of the recipient group 
has approved the sender. The present invention does not require the sender to include a separate 
authorisation code in his/her email, and allows messages to be forwarded that were not pre- 
authoriiced by the sender, but were pre-authori^etl by a member of the at least one recipient 
group. 

The applicant has amended independent claims 1 and 1 1 to clarify that there is provided a system 
for selectively blocking email messages sent by a sender over a communications network to a 
recipient without requiiing prior communication between the sender and the recipient; and, a 
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method of selectively blocking email messages sent by a sender over a communications network 
to a recipient without requiring prior communication between the sender and tlie recipient. 

The amendments further clarify that the decision to forward the email message is determined by 
the sender having been authorized by either the recipient or at least one member of the recipient 
group of which the recipient is a member. Support Ibr the amendments is found at paragraphs 8 
and 26. 

Having regard to the above, favorable reconsideration and allowance of this application are 
respectfully requested. The Commissioner is authorized to charge any required fees, including 
the RCE fee set tbrth in 37 CFR 1 . 1 7(e), to our Deposit Account No. 500663. 

Executed at Toronto, Ontario, Canada, on September 14, 2007, 

Tristan Goguen 



Etienne de Villiers 
Re^stration No, 58,632 
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